home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0024-Fail 'QUIT' for app-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  4.9 KB  |  145 lines  |  [TEXT/GEOL]
  1. Item    6335104                         7-June-89        21:32
  2.  
  3. From:   D1716                           Intelligent Sys Design,G Storm, PRT
  4.  
  5. To:     BURBECK.S                       Burbeck, Steve
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    Fail 'QUIT' for app wk file
  10.  
  11. Subject:            Fail 'QUIT' for apps that use work files
  12.  
  13.     While working on a large multi-media knowledge base application, I
  14. discovered a problem in MacApp that only occcurs under very specific
  15. circumstances.  The application I am  developing handles extremely large
  16. amounts of information from a diverse set of media.  For this reason, I have
  17. implemented the software in a manner similar to the DemoCards example.  All
  18. changed information is written onto a work file which is then merged with the
  19. original data file when saved.  The program uses the templates defined by the
  20. objects for storage and retrieval of all information on any of the files
  21. involved.  These object templates are primarily defined as 'views' and also
  22. properly display the information to the user.
  23.  
  24.     The problem is that if the user chooses 'quit' and then responds with a
  25. 'yes' to a request to save the data, the views the save routines in the
  26. application uses to read and write the information are closed prior to the
  27. save.  Normally I would have solved this type of problem by overriding the
  28. appropriate method and substituting code to make the system behave in the
  29. manner desired.  In this case  however I found that a very slight change to
  30. MacApp achieved the desired effect without causing problems with any of the
  31. software I have available to test the system.  The major visible effect of the
  32. change I have made is that the save performed under the circumstances outlined
  33. above is performed prior to the windows on the screen being closed rather than
  34. after the windows are closed.
  35.  
  36.     When running optimized code the effects of this change are minimally
  37. evident to the user, but extremely critical to applications which may need the
  38. 'view' objects around a little while longer to complete the save.  The details
  39. of the change I have instituted are limited to one method in 2.0b5
  40. (TApplication.Close) and are detailed below.  The change requires moving two
  41. lines of code found in this method.
  42.  
  43. Change FROM:
  44.  
  45.         PROCEDURE TApplication.Close;
  46.         VAR
  47.                 wmgrWindow:    WindowPtr;
  48.  
  49.             {-------------------------------+
  50.             |    FreeIt                        |
  51.             +-------------------------------}
  52.             PROCEDURE FreeIt(anEvtHandler: TEvtHandler);
  53.             BEGIN
  54.                     anEvtHandler.Free;  { ??? also call Terminate ??? }
  55.             END;
  56.  
  57.             {-------------------------------+
  58.             |    CloseADocument                |
  59.             +-------------------------------}
  60.             PROCEDURE CloseADocument (aDocument: TDocument);
  61.  
  62.             BEGIN
  63.                     aDocument.Close;
  64.             END;
  65.  
  66.         BEGIN
  67.             { Close all of the windows }
  68.                 REPEAT
  69.                         wmgrWindow := FrontWindow;
  70.                         IF wmgrWindow <> NIL THEN
  71.                             CloseWmgrWindow(wmgrWindow);
  72.     UNTIL wmgrWindow = NIL;
  73.  
  74.                 { Close any windowless documents }
  75.                 ForAllDocumentsDo(CloseADocument);        {causes big problems here}
  76.  
  77.                 gPrintHandler.Terminate;
  78.                 EachHandler(gHeadCoHandler, FreeIt);
  79.                 IF LoadScrap <> noErr THEN; { ??? }
  80.         END;
  81.  
  82.  
  83. Change TO:
  84.  
  85.         PROCEDURE TApplication.Close;
  86.         VAR
  87.                 wmgrWindow:    WindowPtr;
  88.  
  89.             {-------------------------------+
  90.             |    FreeIt                        |
  91.             +-------------------------------}
  92.             PROCEDURE FreeIt(anEvtHandler: TEvtHandler);
  93.             BEGIN
  94.                     anEvtHandler.Free;  { ??? also call Terminate ??? }
  95.             END;
  96.  
  97.             {-------------------------------+
  98.             |    CloseADocument                |
  99.             +-------------------------------}
  100.             PROCEDURE CloseADocument (aDocument: TDocument);
  101.  
  102.             BEGIN
  103.                     aDocument.Close;
  104.             END;
  105.  
  106.         BEGIN
  107.                 { Close any windowless documents }
  108.                 ForAllDocumentsDo(CloseADocument);     {location seems better}
  109.  
  110.                 { Close all of the windows }
  111.                 REPEAT
  112.                         wmgrWindow := FrontWindow;
  113.         IF wmgrWindow <> NIL THEN
  114.                             CloseWmgrWindow(wmgrWindow);
  115.                 UNTIL wmgrWindow = NIL;
  116.  
  117.                 gPrintHandler.Terminate;
  118.                 EachHandler(gHeadCoHandler, FreeIt);
  119.                 IF LoadScrap <> noErr THEN; { ??? }
  120.         END;
  121.  
  122.     As I said earlier, I am generally reluctant to make any changes to MacApp
  123. directly when it is so easy to override methods that contain code that is
  124. undesireable to my particular needs.  I feel, however, that this particular
  125. change is a reasonable modification to the system and is entirely necessary for
  126. larger applications that handle huge volumes of data using some form of work or
  127. scratch files for changes.  I hope you will consider this recommendation, and
  128. inform me of your opinions regarding this overly long dissertation. Thanks for
  129. your time.  Sincerely,
  130.  
  131. Michael R. Staley
  132. Manager Software Development
  133.  
  134. Intelligent Systems Design, Inc.
  135. NCR Center  Suite 101
  136. 15400 S.E. 30th Place
  137. Bellevue, WA  98007-6546
  138.  
  139. Direct:     (512) 650 - 3917
  140. Phone:              (206) 641-8012
  141. Fax:                    (206) 641-8233
  142. AppleLink:      D1716
  143.  
  144.  
  145.